10장 클래스
Intro
코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도
좀 더 차원 높은 단계까지 신경쓰지 않으면 깨끗한 코드를 얻기는 어렵다.
클래스 체계
표준 자바 관례에 따르면, 변수 목록이 가장 먼저 나온다.
[변수 목록] : 정적(static), 공개(public) 상수 -> 정적 비공개(private) -> 비공개 인스턴스 변수
[변수 목록] -> [공개 함수] -> [비공개 함수]
즉, 추상화 단계가 순차적으로 내려간다.
그래서 신문처럼 읽힌다.
캡슐화
같은 패키지 안에서 테스트 코드가 함수를 호출하거나 변수를 사용해야 한다면
그 함수나 변수를 protected로 선언하거나 패키지 전체로 공개한다.
캡슐화를 풀어주는 결정은 언제나 최후의 수단이다.
클래스는 작아야 한다!
함수는 행 수로 크기를 측정했다면, 클래스는 맡은 책임을 센다.
클래스 이름에 Processor, Manager, Super 등과 같이 모호한 단어가 있다면
클래스에다 여러 책임을 떠 안겼다는 증거다.
또한 클래스 설명을 만일("if"), 그리고("and"), -(하)며("or"), 하지만("but")을 사용하지 않고서
25단어 내외로 가능해야 한다.
단일 책임 원칙
단일 책임 원칙(Single Responsibility Principle, SRP)은
클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다.
큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다.
작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며,
다른 작은 클래스와 합력해 시스템에 필요한 동작을 수행한다.
응집도
우리는 응집도가 높은 클래스를 선호한다.
응집도가 높다는 것은 클래스에 속한 매서드와 변수가 서로 의존하며
논리적인 단위로 묶인다는 의미다.
‘함수를 작게, 매개변수 목록을 짧게’라는 전략을 따르다보면,
때때로 몇몇 메서드만이 사용하는 인스턴스 변수가 만하진다.
그럴 땐 새로운 클래스로 쪼개야한다.
응집도를 유지하면 작은 클래스 여럿이 나온다
저자는 커누스 교수가 쓴 책 ‘Literate Programming’에 나오는 예제를 소개한다.
리팩털이한 결과 프로그램이 늘어났다.
- 좀 더 길고 서술적인 변수 이름 사용
- 코드에 주석을 추가하는 수단으로 함수 선언과 클래스 선언 활용
- 가독성을 높이고자 공백을 맞추고 형식을 맞춤
변경하기 쉬운 클래스
클래스에 손대는 순간 설계를 개선하려는 고민과 시도가 필요하다.
또한 클래스 일부에서만 사용되는 비공개 매서드는 코드를 개선할 잠재적인 여지를 시사한다.
저자는 예시로 sql클래스를 들었다.
여기서 SRP와 OCP를 챙긴다.
즉, UpdateSql 클래스를 제자리에 끼워 넣으면 끝난다.
이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 건드리지 않는다.
변경으로부터 격리
우리는 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다.
시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다.
결합도를 최소로 줄이면 DIP(Dependency Inversion Principle)를 따르는 클래스가 나온다.
DIP는 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙이다.
결론
함수와 같은 것 같다.
인스턴스가 많으면 쪼개서 응집도를 높인다.
그러다 특정 매서드에만 쓰이는 변수가 많아지면 클래스를 쪼갠다.
클래스는 책임이 하나인지를 집중해서 살펴본다.
즉, 쪼개라!!